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Preface 


This  thesis  describes  the  application  of  Structured  Analysis  and 
Structured  Design  methodologies  to  design  the  software  to  simulate  a 
specialized  and  complex  aircraft  simulator.  The  key  to  the  successful 
development  of  a software  design  is  a complete  and  understandable  re- 
quirements definition.  Structured  Analysis  facilitates  the  building 
of  a requirements  definition  that  gradually  exposes  the  detail  of  the 
system  and  is  well  structured.  Using  this  well-structured  requirements 
definition  and  the  Structured  Design  methodology,  a software  structure 
is  designed  that  makes  coding,  debugging,  and  modification  easier  and 
faster  by  reducing  complexity,, 
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This  thesis  contains  an  analysis  of  a Visually  Coupled  Airborne 


Systems  Simulator  (VCASS)  and  the  design  of  the  software  for  this 
system.  The  design  is  developed  in  three  steps.  First,  an  informal 
requirements  definition  is  written  to  establish  the  viewpoint  and  the 
purpose  on  which  the  analyst.  bases  his  design.  This  requirements  def- 
inition explains  why  the  simulator  is  to  be  created  and  what  it  is  to 
do.  Second,  a top-down  strategy  called  "structured  analysis"  is  applied 
to  obtain  a formal  requirements  definition.  The  structured  analysis  is 
presented  in  a blueprint-type  language  consisting  of  activity  and  data 
models.  These  models  represent  graphically  the  functions  performed  by 
the  simulator  and  the  information  upon  which  those  functions  act.  Third, 
a design  is  obtained  through  a structured  design  methodology  consisting 
of  "transform  analysis"  and  "transaction  analysis"  techniques.  The 
structure  charts  drawn  during  the  analysis  phase  reveal  system  character- 
istics which  illustrate  design  quality.  The  activity  model  is  used  to 
make  a successful  transition  from  a top-down  analysis  to  a structured 
design  which  can  be  evaluated.  The  resulting  simulator  design,  with 
minor  revisions,  satisfies  the  design  goals  established  for  the  project. 
The  methodologies  used  are  highly  recommended  for  the  analysis  and  design 
of  any  software  system. 
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SOFTWARE  DESIGN  FOR  A VISUALLY-COUPLED 
AIRBORNE  SYSTEMS  SIMULATOR  (VCASS) 

I.  Introduction 

Background 

Because  of  increasing  costs  for  fuel  and  aircraft,  the  Air  Force 
has  been  forced  to  cut  the  number  of  flight  hours  of  pilot  training  in 
the  aircraft.  As  planes  become  more  complex,  the  pilots  require  more 
training  to  maintain  their  flying  proficiency.  The  Air  Force  is, 
therefore,  faced  with  the  problem  of  obtaining  more  training  for  the 

pilots  while  still  keeping  the  number  of  actual  aircraft  training  flights 

If 

to  a minimum. 

A present  solution  is  the  fixed-based  flight  simulator.  This 
simulator  utilizes  electro-optical  devices  to  project  video  imagery 
(generated  from  a sensor  scan  of  a terrain  board  or  from  computer- 
generated imagery)  onto  a hemispherical  dome  (or  set  of  large  adjacent 
CRT  displays  arranged  in  optical  mosaics).  Most  types  of  simulators  do 
not  incorporate  infinity  optics  or  provide  collimated  visual  scenes  to 
the  operator.  Those  which  do  sire  large  and  expensive.  The  fixed-based 
simulator,  also,  does  not  allow  the  flexibility  of  incorporating  other 
display  design  factors,  such  as  different  head-up  display  formats, 
variable  fields-of-view,  representative  cockpit  visibilities,  and  op- 
tional control  and  display  interfaces. 

The  visually  coupled  systems  (VCS)  is  an  approach  to  solving  the 

j visual  presentation  problems  of  aircraft  simulators.  VCS  includes  a 

* 

combination  of  a helmet-mounted  sight  (HMS),  eye  position  sensing  system 
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(EPS),  and  helmet  mounted  displays  (HMD).  It  is  through  the  VCS  concepts 
that  the  idea  of  a Visually  Coupled  Airborne  Systems  Simulator  (VCASS) 
came  into  being. 

VCASS  is  a flexible,  visual  scene  simulator  providing  synthesized 
out-of-the  cockpit  visual  scenes  and  targets.  It  is  also  used  to  repre- 
sent an  aircraft  whose  type,  threat,  and  weapons  dynamics  can  be  altered 
with  flexibility  of  control  and  display  configurations.  VCASS  can  be 
used  to  simulate  either  air-to-ground  weapons  delivery  or  air-to-air 
engagement  scenarios. 

A system  block  diagram  of  the  functional  elements  required  to 
accomplish  VCASS  is  shown  in  Figure  1.  The  operator  utilizes  conven- 
tional control  devices  (control  stick,  throttle,  rudder  pedals,  -c.) 
as  input  to  a digital  computer  which  provides  the  manipulation  of  the 
vehicle,  threat,  and  weapon  states  as  a function  of  preprogrammed  dynamic 
characteristics.  This  input  is  used  to  manipulate  generated  symbology 
and  imagery  in  terms  of  aircraft  orientation,  scale,  target  location, 
etc.  A visual  scene  (generated  by  the  graphics  or  sensor  imagery 
generators)  is  selected  by  the  operators  line-of-sight  orientation,  as 
measured  by  the  helmet-mounted  sight  sensors.  The  helmet  display  elec- 
tronics receives  the  selected  portion  of  the  symbology  and  sensor  informa- 
tion and  displays  the  video  imagery  to  the  operator  through  the  helmet 
display  optics,  in  the  proper  orientation  within  three-dimensional 
space.  The  operator  engages  electronic  targets  (either  air-to-air  or 
air-to-ground)  and  launches  electronic  weapons.  The  operator  performance 
is  assessed  and  recorded  for  future  reference. 


Figure  1.  Visually-Coupled  Airborne  Systems  Simulator 
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Objectives 

This  thesis  is  concerned  vith  designing  the  software  to  accomplish 
the  VGASS  project  objectives.  The  software  design  involves  defining  the 
necessary  subsystems,  programs  or  modules,  and  their  interconnections. 

In  order  to  develop  the  software  design,  it  is  first  necessary  to  define 
the  functional  specifications  of  the  system.  When  the  functional  speci- 
fications are  not  well  defined,  a premature  and  poorly  designed  system, 
leading  to  skyrocketing  costs,  missed  schedules,  waste,  duplication, 
and  disgruntled  users,  often  results  (Ref  5:2).  The  primary  objective 
of  this  thesis  is  to  avoid  such  problems.  To  meet  this  objective,  a 
good  development  technique  is  required.  Structured  analysis  is  such  a 
technique. 

Structured  analysis  is  a comprehensive  methodology  for  performing 
functional  analysis  and  design.  For  this  project,  only  the  functional 
analysis  phase  of  structured  analysis  is  used.  During  this  phase,  the 
emphasis  is  on  analyzing  and  documenting  "what"  the  system  is  supposed  to 
do.  Two  sets  of  diagrams  result:  one  describes  the  system  in  terms  of 
activities  and  the  other  describes  the  system  in  terms  of  data.  These 
diagrams  are  created  by  decomposing  the  system  into  smaller  and  smaller 
pieces.  The  two  sets  of  diagrams  are  cross-checked  and  sequenced  to 
provide  a model  of  the  system  functions.  This  model  provides  the  base 
for  the  design  (Ref  6:  1-1,  1-2). 

After  the  functional  specifications  are  defined,  the  software 
structure  is  designed  through  the  application  of  structured  design 
techniques.  Structured  design  is  a set  of  general  program  design  con- 
siderations and  techniques  for  making  coding,  debugging  and  modification 
easier,  faster,  and  less  expensive  (Ref  8:114).  It  simplifies  the 


4 


software  by  dividing  it  into  modules  in  such  a way  that  modules  can  be 
Implemented  and  modified  with  minimal  consideration  or  effect  on  the 
other  parts  of  the  system.  A graphical  tool,  called  structured  charts, 
is  used  to  present  the  software  structured  design.  The  interface  be- 
tween the  modules  is  given,  along  with  a functional  description  of  each 
module. 

The  sponsor  of  this  thesis  is  the  6570  Aerospace  Medical  Research 
Laboratory  (AMRL),  located  at  Wright-Patterson  Air  Force  Base,  Ohio. 
Their  mission  has  been  to  optimize  the  visual  interface  of  crew  members 
to  advanced  weapon  systems.  This  mission  has  been  primarily  pursued  in 
two  areas:  (l)  the  establishment  of  control  and  display  engineering 
criteria,  and  (2)  the  prototyping  of  advanced  concepts  of  control  and 
display  interfaces.  The  development  of  an  operational  VCASS  system 
will  be  an  important  step  in  fulfilling  this  mission. 


Scope 

The  purpose  of  this  thesis  is  to  develop  a software  design  that 
meets  the  requirements  of  the  VCASS  concept.  In  addition  to  the  normal 
VCASS  functions,  this  software  design  will  allow  for  a systematic  in- 
vestigation of  display  symbology  and  line  graphics  representation  of 
terrain  and  target  features. 

This  thesis  is  limited  to  the  software  design  of  the  proposed 
system.  The  hardware  or  any  associated  controls  are  defined  only  in 
terms  of  the  input/output  interfaces  between  the  helmet  sight/di splay 
components,  simulator  cockpit  controls,  graphics  generators,  and  any 
interactive  keyboard  consoles.  The  resultant 'design  gives  a modular 
structure  identifying  all  inputs  and  outputs.  These  modules  when  fully 
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coded,  should  produce  a system  that  will  be  modifiable,  maintainable, 
and  effective  in  simulating  the  VCASS. 


Plan  of  Development 

The  requirements  definition  with  emphasis  on  the  functional 
specifications  is  discussed  in  Chapter  II.  Chapter  III  presents  the 
formal  functional  specifications  for  the  system.  These  specifications 
are  in  the  form  of  activity  and  data  models.  They  are  the  result  of 
the  functional  analysis  phase  of  Sof tech's  Structured  Analysis  and 
Design  Technique  (SADT).  Chapter  IV  presents  the  software  design.  The 
design  is  illustrated  with  structured  charts  and  data  flow  graphs  (bubble 
charts)  along  with  the  functional  descriptions  of  the  modules.  A dis- 
cussion of  the  techniques  used  in  the  design  of  the  system  along  with 
conclusions  and  recommendations  are  contained  in  Chapter  V. 


The  normal  life-cycle  for  a computer  software  development  project 
consists  of  the  following  seven  phases  (Ref  2:  5-8)!  conceptual,  re- 

quirements definition,  design,  coding,  checkout,  testing,  and  operational. 
The  phase  most  often  underutilized,  or  even  neglected,  is  the  require- 
ment definition.  A poor  requirements  definition  usually  results  in 
rising  costs,  missed  schedules,  waste,  duplication,  and  dissatisfied 
users.  (Ref  5:2).  Neglect  in  this  phase  often  results  in  an  incomplete 
documentation  package.  This  lack  of  documentation  leads  to  more  wastage 
when  a system  has  to  be  ’’redeveloped"  for  a modification  change. 

In  this  thesis  the  requirements  definition  deals  with  three 
interrelated  subjects:  context  analysis,  design  constraints,  and 
functional  specifications.  The  context  analysis  tells  why  the  VCASS 
system  is  being  createdj  this  is  discussed  in  the  background  section  of 
Chapter  I.  The  design  constraints  tell  how  the  VCASS  system  is  to  be 
constructed;  these  are  discussed  in  the  next  section  of'  this  chapter. 

The  functional  specifications  describe  what  the  system  is  to  do  and  are 
discussed  informally  in  a later  section  of  this  chapter  and  formally  in 
Chapter  III. 

Design  Constraints 

This  section  is  a summary  of  the  conditions  specifying  how  the 


VCASS  software  is  to  be  constructed.  No  particular  hardware,  such  as 
input  or  output  devices,  will  be  specified  since  these  details  should 
be  specified  in  a later  stage  of  the  design  (Ref  5s4)» 


The  four  accepted  goals  of  the  discipline  of  software  engineering 
are  modifiability,  efficiency,  reliability,  and  understandability.  (Ref  1:92) 
These  goals  were  the  contraints  used  in  selecting  the  analysis  and  design 
techniques  for  the  design  of  the  VCASS  software.  The  techniques  selected 
are  SofTech's  structured  analysis  for  the  formal  functional  specifications 
and  Yourdon  and  Constantine's  design  method  for  the  software  design. 

Functional  Specifications 

The  system  to  be  designed  is  to  simulate  VCASS.  It  should  accept 
inputs  from  an  aircraft  representative  vehicle,  whose  type,  threat,  and 
weapons  dynamics  can  be  altered;  it  should  provide  synthesized  out-of-the 
cockpit  instrumentation,  visual-  scenes,  and  targets. 

The  software  portion  will  have  two  basic  modes  of  operation. 

Exerciser  and  Operational.  The  Exerciser  mode  allows  the  user  to  interact 
with  the  system  to  build  and  modify  the  formats  for  the  aircraft  symbology 
displays.  During  this  mode  of  operation  the  system  will  output  messages 
to  the  user  in  response  to  the  options  and  parameters  entered.  These 
symbology  displays  are  then  used  under  the  Operational  mode  to  evaluate 
the  pilots  perceptibility.  The  software  design  for  the  Exerciser  mode 
of  operation  is  not  contained  in  this  thesis  but  is  being  designed  as  a 
separate  subsystem  called  the  Symbology  Exerciser  of  the  VCASS  simulator. 

The  design  of  the  Symbology  Exerciser  can  be  found  in  Ref  9.  This  thesis 
defines  the  interface  between  the  Symbology  Exerciser  and  the  VCASS  simulator 

In  the  Operational  mode,  the  system  functions  as  an  aircraft 
simulator.  Flight  control  and  target  inputs  will  be  processed,  according 
to  pre-set  parameters,  to  update  aircraft  instruments,  symbology  displays, 
and  background  imagery.  There  are  four  main  functions  that  will  be 
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performed  In  this  mode.  They  are  (1)  process  configuration  parameters , 

(2)  produce  the  plant  dynamics,  (3)  update  the  aircraft  displays,  and 
(4)  perform  operational  recording.  The  first  function  is  an  initializa- 
tion step  only,  while  the  next  three  functions  are  continuously  repeated 
in  a "real-time"  environment.  A brief  description  of  each  of  these 
functions  follows. 

Process  Configuration  Parameters.  When  the  system  is  put  into  the 
Operational  mode  a message  is  output  to  the  user  requesting  configura- 
tion parameters.  The  user  then  interacts  with  the  system  by  supplying 
the  required  parameters  for  system  options,  vehicles,  weapons,  cockpit, 
target,  environment,  and  display  formats.  The  user  can  choose  to  enter 
all  parameters  or  only  a partial  set  of  parameters.  System  default 
parameters  are  used  for  all  parameters  undeclared  by  the  user. 

1 frequent  user  of  the  system  will  not  have  to  be  prompted  by 
the  system  for  the  parameters,  the  system  will  allow  the  user  to  input 
a command  and  the  parameters  at  the  same  time.  The  system  will  also 
be  capable  of  obtaining  the  parameters  from  a specified  storage  device. 

Configuration  parameters  axe  such  things  as  aircraft  type  and 
characteristics,  weapons  available  and  quantities,  weather  conditions, 
and  target  characteristics.  These  parameters  are  used  to  update  and 
produce  the  plant  dynamics  and  simulation  displays  (aircraft  instruments, 
symbology  displays,  background  imagery,  etc.). 

Produce  Plant  Dynamics.  After  the  configuration  parameters  have  been 
processed,  the  system  enters  a "real-time"  state  and  concurrently  per- 
forms the  functions  'Produce  Plant  Dy  amnios'  and  'Update  Aircraft  Displays'. 

The  information  generated  by  'Produce  Plant  Dynamics'  is  used  by  'Update 
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Aircraft  Displays1  to  make-up  and  update  the  displays.  During  this 
"real-time"  state,  the  system  processes  both  discrete  and  non-discrete 
inputs.  Some  of  the  discrete  inputs  are  vehicle  initialization,  weapons 
mode  selection,  target  mode  selection,  and  visually-coupled  sight  (VCS) 
control  inputs.  The  non-discrete  inputs  must  be  periodically  queried  to 
obtain  the  latest  information.  Some  of  these  inputs  are  vehicle  control, 
weapons  mode,  target  mode,  and  head-mounted-sight  (HMS)  attitude  and 
position  inputs . 

The  function  'Produce  Plant  Dynamics'  uses  both  discrete  and  non- 
discrete  inputs  to  manipulate  the  vehicle,  weapons,  and  target  states. 

The  updated  state  variables  are  then  used  to  compute  and  to  evaluate  the 
attack  performance.  A description  of  the  plant  dynamics  and  the  attack 
performance  follows. 

1.  Vehicle  Dynamics . The  vehicle  position,  angles  and  velocity 
are  initially  entered.  Vehicle  flight  control  inputs,  such  as  stick, 
rudder,  and  throttle,  are  then  used  to  compute  and  update  the  appropriate 
vehicle  state  variables. 

2.  Weapons  Dynamics.  The  aircraft  weapons  are  activated  through 
one  of  three  modes  specified  by  the  operator.  The  modes  are  gun,  air-air 
missile,  and  air-ground.  When  any  of  these  modes  are  activated,  the 
aircraft  and  its  associated  weapons  are  setup  for  release.  This  setup 
includes  checking  the  weapons,  activating  the  sights,  and  determining  the 
lead  angles. 

3.  Target  Dynamics.  There  are  three  types  of  targets:  canned, 
semi-smart,  and  smart.  The  canned  target  flight  path  is  based  upon  a 
pre-programmed  table-lookup.  The  flight  path  of  the  semi-smart  target 
is  obtained  from  a pre-programmed  table  based  upon  the  attacking  vehicles 


maneuvers . The  smart  target  is  maneuvered  by  a computer  algorithm 
vhich  is  based  upon  the  state  of  the  vehicle  and  the  state  of  the  target. 

4*  Attack  Performance.  The  two  types  of  scenario  to  be  evaluated 
are  air-air  and  air-ground.  The  scenario  is  determined  by  the  weapons 
mode.  The  weapon  trajectory  and  probability  of  a hit,  which  are  used 
to  evaluate  the  air-air  scenario,  are  computed  using  the  position, 
angles,  and  rate  of  the  aircraft  and  target.  The  weapons  drag  coefficients 
are  also  included  in  this  computation. 

To  evaluate  the  air-ground  scenario  the  accuracy  of  the  simulated 
air-to-ground  weapons  delivery  is  determined.  The  known  characteristics 
of  the  weapons  motion  and  the  weapons  release  point,  are  used  to  compute 
the  impact  point.  This  impact  point  is  compared  with  the  known  target 
location  to  compute  a miss  distance  and  angle. 

Pedate  Aircraft  Displays.  The  plant  dynamics  and  simulation  specific 
inputs  are  used  to  update  the  cockpit  instruments  and  aircraft  displays. 

The  cockpit  instruments  are  similar  to  the  instruments  found  in  an 
aircraft  cockpit  and  are  updated  from  the  respective  vehicle  state  varia- 
bles. These  instruments  include  the  fuel  gauge,  magnetic  compass,  airspeed 
indicator,  altimeter  and  power  indicator. 

The  aircraft  displays  consist  of  three  different  types  of  hardware 
display  devices,  each  requiring  its  independent  software  package.  They 
are  (1)  the  helmet  mounted  display  (HMD),  (2)  the  panel  display,  and 
(3)  the  heads-up  display  (HUD).  The  panel  and  the  HMD,  display  a field- 
of-view  portion  of  the  outside  world  display,  presenting  the  proper 
orientation  within  a three-dimensional  space.  The  HMD  and  the  panel 
display  are  different  in  that  the  HMD  is  oriented  with  respect  to  the 
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operator  line-of-sight,  while  the  panel  display  is  oriented  with  respect 
to  the  aircraft  heading. 

The  displays  that  can  be  output  on  the  HMD  and  the  panel  display 
are  the  flight  simulated  display  (FSD),  the  simulated  HUD  display,  the 
vehicle  velocity  hemispherical  display  (WHD) , the  terrain  portrayal 
display,  the  background-environment  display,  the  target,  and  the  weapons 
envelope.  In  addition  to  the  above  displays,  the  HMD  also  displays  the 
tables  and  menus.  A description  of  these  displays  follows. 

Since  the  HUD  display  can  be  simulated  on  the  HMD  and  panel  display, 
the  description  of  the  HUD  is  the  same  as  the  description  for  the  simu- 
lated HUD  in  the  FSD/simulated  HUD  description  below. 

1.  FSD/Simulated  HUD.  Figure  2 illustrates  a typical  format  of 
the  FSD  or  the  simulated  HUD  display.  Some  of  the  information  shown  in 
the  FSD  and  in  the  simulated  HUD  display  are  altitude,  heading,  airspeed. 


XXXX  RTCH/ROLL  XXXX 

LADDER 

Figure  2.  FSD/ Simulated  HUD  Displays 
12 
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pitch,  roll,  aircraft  horizon,  and  the  real  horizon.  The  FSD  and  simulated 
HDD  do  not  always  display  the  same  information  or  have  the  same  format. 

Both  give  a graphic  representation  of  the  aircraft  state,  but  the  HDD 
changes  according  to  the  flight  mode  while  the  FSD  does  not.  The  flight 
modes  are  takeoff,  enroute,  landing  and  attack. 

2.  Vehicle  Velocity  Hemispherical  Display  (WHD).  Figure  3 
illustrates  a typical  format  of  the  WHD  display.  The  simulated 
horizon  lines  depict  the  horizon  of  the  real  earth.  The  converging 
dashed  lines  move  toward  the  operator  as  a function  of  the  vehicle 
velocity.  The  amount  of  convergence  or  divergence  of  these  lines  is  a 
function  of  the  vehicle  altitude.  This  display  orients  the  operator 
with  respect  to  the  vehicle  altitude,  ground  speed,  and  heading. 


A 


3.  Terrain  Portrayal.  The  terrain  portrayal  la  a graphical 
representation  of  the  earth.  This  representation  is  presented  as  a set 
of  different  grid  patterns.  The  particular  pattern  displayed  is  a func- 
tion of  the  vehicle  altitude.  This  display  acts  as  a reminder  to  the 
operator  of  the  vehicle  attitude  and  altitude  changes. 

4*  Background  and  Environment.  The  background  and  environment 
is  a graphical  simulation  of  the  world  outside  the  cockpit.  It  contains 
graphical  features  such  as  mountains,  rivers,  runways  and  buildings. 

5.  Target.  The  target  display  is  a graphical  representation  of 
an  aircraft.  The  target  motion  is  derived  from  a series  of  table  look- 
ups, an  algorithm,  or  a combination  of  both. 

6.  Weapon  Envelopes.  The  weapons  envelope  is  a graphical  repre- 
sentation of  the  effective  radius  of  the  weapon.  This  display  is  used  by 
the  pilot  to  tell  when  a target  is  within  effective  range  of  the  selected 
weapon. 

7.  Table  and  Menu.  The  table  and  menu  displays  give  the  operator 
the  opportunity  to  select  different  HMD  displays.  It  also  allows  the 
operator  to  enter,  delete,  or  change  system  data  while  in  the  Operational 
mode.  For  example,  the  FLY-TO-POINTS  menu  display  would  be  used  to 
enter  'he  coordinates  of  flight  destination  points. 

Operational  Recording.  A history  of  nil  inputs,  outputs,  and  selected 
variables  is  maintained  on  a recording  device.  The  recording  contains 
such  information  as  hardware  errors,  operator  errors,  terminal  responses, 
computed  plant  dynamics,  attack  performance,  simulation  specific  inputs, 
and  plant  specific  inputs.  It  will  be  used  to  evaluate  the  pilot  and 


access  his  reactions  to  various  stimuli. 


Chapter  I presented  the  context  analysis  of  the  problem  which  forms 
a perspective  from  which  to  view  the  overall  problem.  This  chapter 


presented  the  constraints  for  the  problem  solution  and  the  informal 
functional  specifications.  Hie  design  constraints  are  imposed  by  the 

i 

desired  design  goals.  Analysis  and  design  techniques  are  selected  so 
the  design  meets  these  goals.  The  informal  functional  specifications 
in  this  chapter  form  the  basis  for  the  construction  of  SADT  activity  and 
data  models  in  the  next  chapter. 

‘ 
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Introduction 

The  formal  functional  specifications  of  the  system  are  developed 
using  the  functional  analysis  phase  of  Softech  Structured  Analysis  and 
Design  Technique  (SADT).  The  emphasis  is  on  analyzing  and  documenting 
"what"  the  system  is  supposed  to  do.  Two  sets  of  diagrams  result:  one 
type  describes  the  system  in  terms  of  activities  and  the  other  type 
describes  the  system  in  terms  of  data.  Thes**  diagrams  are  created  by 
decomposing  the  system  into  smaller  and  si  -er  sections.  The  two  sets 
of  diagrams  are  cross— checked  for  consistency  to  provide  a model  of  the 
system  functions,  which  makeup  the  formal  functional  specifications. 

These  diagrams  represent  the  conceptual  ideas  conveyed  by  the  function 

i 

specifications,  which  were  discussed  in  Chapter  II. 

The  activity  and  data  models  are  presented  in  this  chapter  and  are 
organized  as  a sequence  of  diagrams  with  the  supporting  text.  The 
activity  model  is  presented  first  followed  by  the  data  model.  Before 
reading  the  activity  or  data  diagrams,  scan  the  corresponding  "node 
index",  which  serves  as  a table  of  contents.  This  index  gives  an  over- 
view of  the  decomposition  structure. 

A brief  discussion  of  how  to  read  structured  analysis  diagrams 
can  be  found  in  Appendix  A. 


Node 


Title 


A-0 

AO 

A1 

All 

A13 

A14 

A15 

A2 

A21 

A22 

A23 

A233 

A234 

A24 

A25 

A26 

A3 

A31 

A32 

A321 

A322 

A324 

A3243 

A325 

A326 

A3263 

A33 

A35 

A36 


Simulate  TCASS 
Simulate  VCASS 
Process  User  Commands 
Get  Valid  Command 
Configure  System 
Give  Terminal  Response 
Output  Operational  Recording 
Produce  Plant  Dynamics 
Process  Inputs 

Compute  Vehicle  Plant  Dynamics 
Compute  Target  Plant  Dynamics 
Control  Semi-Smart  Mode 
Control  Smart  Mode 
Compute  Weapons  Plant  Dynamics 
Compute  Attack  Performance 
Output  Operational  Recording 
Update  Aircraft  Displays 
Process  Inputs 
Update  Symbology  Displays 
Format  Inputs 
Makeup  Table/Menu 
Makeup  HMD 

Makeup  HUD  Display  (HMD) 

Makeup  HUD 

Makeup  Panel  Displays 
Makeup  HUD  Display  (panel) 

Update  Imagery  Displays 
Output  Displays 
Output  Operational  Recording  74 


This  activity  model  provides  the  formal  functional  specifications  for  the 
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AO  Text:  A user  cosmand  (1C1)  la  received  by  'Process  User  Comnands'  (l).  The  oonnand  Is  either  an 


Figure  6,  Process  User  Commands 


A1  Text i User  conmanda  (1C1)  are  ohedked  by  (1)  to  determine  validity.  If  they  are  invalid,  an  error 


Figure  7.  Get  Valid  Command 


'Check  Command ' (1)  checks  user  commands  (1C1)  to  see  if  they  are  valid.  For  co 


Figure  6.  Configure  System 


Figure  9.  Give  Terminal  Response 


Figure  10.  Output  Operational  Recording 


(Ill)  and  the  terminal  responses  (112)  are  formatted  by  (l)  Into  the 


The  plant  specific  Inputs  (111)  (such  as  throttle,  stick  and  rudder  inputs)  are  received  by 


The  plant  specific  inputs  (611),  plant  state  variables  (613) * and  performance  measure  (613) 
recorded  by  (6)  as  part  of  the  system  history  (602). 


Figure  13.  Compute  Vehicle  Plant  Dynamics 


The  a tick  inputa  (1C2),  rudder  inputs  (1C2),  and  vehiole  configuration  (1C1)  are  used  by 


Figure  14*  Compute  Target  Plant  Dynamics 


Figure  15.  Control  Semi-Smart  Mode 


Figure  16.  Control  Smart  Mode 
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When  in  the  air-air  node  (1C2),  the  veapon  trajectory  (101)  la  computed  by  (1), 


Figure  19.  Output  Operational  Recording 


Figure  20.  Update  Aircraft  Displays 


The  simulation  specific  Inputs  (VCS  control,  discrete,  HMS  attitude 


display  device  by  (5).  The  simulation  specific  inputs  (611)  are  recoiled  by  (6)  as  part  of  the  system 


Figure  21.  Process  Inputs 


1 Text:  'Check  Inputs'  (1)  receives  simulation  specific  Inputs  (1C1)  and  checks  them  for  validity 


Figure  22.  Update  Symbology  Displays 


Makeup  Table/Menu 


Figure  25.  Makeup  HMD 


Figure  27.  Makeup  HOD 


ip  Paiel  Displays 


103,  104)  Is  determined  by  (1)  from  the  HOD  display  request 


figure  30.  Update  Imagery  Displays 


Text:  The  helmet  mounted  sight  (HMS)  attitude  and  position  (1C1) , vehicle  state  variables  (1C2) 


Figure  31.  Output  Displays 


Operational  Recording 


The  error  type  (101)  la  determined  by  (1)  from  the  input  error  message  (1C1).  The  error 


Purpoae  and  Viewpoint i This  data  model  provides  the  formal  functional  specifications  for  the  VC ASS 


of  the  plant  data  (4) . Specific  portions  of  the  updated  plant  data  (4)  are  delivered  (401)  as  perfor- 
mance data  (5)  to  be  output  on  the  operational  recording  (501).  The  p]  t data  (4)  is  also  used  in 
conjunction  with  the  initial  data  (2)  to  produce  the  simulation  displays  (6).  The  processing  of  the 
simulation  specific  inputs  (6C1),  such  as  determining  the  display  modes,  constrains  the  production 


DATA 


Figure  36.  Analog/Digital  Inputs 


03  Text i The  vehicle  Inputs  (1)  (such  as  stick,  rudder,  and  throttle),  target  Inputs  (2)  (such  as 


Figure  38.  Performance  Data 


Simulation  Displays 


This  chapter  presented,  for  VC ASS,  the  activity  and  data  models, 
which  are  the  formal  specifications  of  the  system.  These  specifications 
are  the  basis  from  which  the  software  design  in  chapter  IV  is  developed. 


Since  none  of  the  activity  names,  data  names  or  arrow  labels  are 
binding,  some  of  corresponding  names  and  labels  in  the  next  chapter 
have  been  changed  to  aid  in  the  understanding  of  the  software  design. 


IV.  Software  Design 


Introduction 

The  purpose  of  the  design  phase  is  to  define  the  functions  and 
operations  necessary  to  satisfy  the  system  requirements.  The  intent 
of  this  thesis  is  to  design  the  software  structure  which  will  be  used 
in  implementing  the  VCASS  system.  As  stated  in  Chapter  I this  thesis 
presents  only  a part  of  the  design  phase. 

The  technique  utilized  is  called  structured  design.  Structured 
design  is  a set  of  general  program  design  considerations  and  techniques 
for  making  coding,  debugging,  and  modification  easier,  faster,  and  les3 
expensive  by  reducing  complexity  (Ref  8:  115).  It  simplifies  the  soft- 
ware by  dividing  it  into  modules  which  can  be  implemented  and  modified 
with  ml nlmal  effects  on  other  parts  of  the  system.  The  criteria  for 
evaluating  the  design  is  measured  by  the  following  attributes:  (1) 
coupling,  (2)  cohesion,  (3)  span-of-control,  and  (4)  scope-of-effect 
(Ref  10:  340). 

Structured  design  starts  by  stating  the  problem  as  a data  flow 
graph  (or  bubble  chart).  This  bubble  chart  represents  the  conceptual 
ideas  conveyed  by  the  formal  functional  specifications  (in  Chapter  III) 
A first  cut  is  obtained  by  factoring  the  bubble  chart  into  a tree 
structure  known  as  a "structure  chart".  The  resulting  design  is  then 
evaluated,  and  revised,  according  to  the  above  attributes.  Inter- 
actions, between  the  structure- to-bubble  chart  «nd  bubble- to-structure 
chart  further  refine  the  design.  The  resulting  bubble  chart  and 
structured  charts  are  presented  in  this  chapter. 


Bubble  Chart 


1 bubble  chart  transforms  "conceptual  Inputs"  Into  "conceptual 
outputs"  and  consists  of  "transforms"  connected  by  labeled  arrows. 

These  "transforms",  which  are  the  basic  elements  of  the  bubble  chart, 
are  represented  by  circles  labeled  with  short  description  of  the 
transformations . 

The  asterisk  ("*")  is  used  to  indicate  an  "and"  relationship 
between  data  elements.  The  "ring-sum"  operator  ("9")  is  used  to  denote 
"exclusive-or"  relationships  between  data  elements.  Bubbles  and  arrows 
are  drawn  to  represent  input  branches  and  output  branches.  These 
branches  are  connected  by  bubbles  which  are  the  "central  transforms"  of 
the  system.  The  "central  transforms"  converts  the  "conceptual  inputs" 
into  "conceptual  outputs".  Identified  on  the  bubble  charts  are  the 
"afferent"  and  "efferent"  data  elements.  An  "afferent"  data  element 
is  an  input  to  a "central  transform";  and  an  "efferent"  data  element 
is  an  output  from  a "central  transform".  The  dashed  lines  and  the 
dashed  circle  on  this  particular  bubble  chart  represent  a portion  of 
the  overall  VCASS  system  software  design  which  is  not  contained  in 
this  thesis,  but  is  being  modeled  separately  (Ref  9). 

The  final  bubble  chart  for  the  VCASS  system  software  design  is 
shown  in  Figure  1 and  represents  the  conceptual  ideas  conveyed  by  the 
formal  functional  specifications  in  Chapter  III. 


The  transfers  'Get 


The  structure  charts  for  the  VC ASS  system  software  design  Eire  shown 
in  Figures  41  through  61.  They  are  organized  as  a sequence  of  charts 
with  the  associated  documentation.  The  documentation  includes  the 
input/output  tables  (interface  between  modules)  and  a description  of  the 
modules.  To  aid  the  reader  in  understanding  the  design,  a brief  dis- 
cussion of  how  to  read  structured  charts  can  be  found  in  Appendix  B. 


Figure  41*  Top  Level  w-ructure 


Module  Descriptions  for  Tod  Level  Structure 


ceives  and  processes  plant  discrete  inputs:  vehicle  initialization!  weapons  node  selection!  and  target 


Figure  42.  PERFORM  COMMAND  Branch 


Table  II 


Module  Deacrlptlona  for  PERFORM  COMMAND  Branch 


Figure  43.  GET  VALID  COMAND  Branch 


Figure  44.  CONFIGURE  SIMULATION  Branch 


Table  IV 
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10, 13, 16, 19,22,25,28  Respective  parameter  request  Respective  configuration  parameters,  Respective  El 

CONFIGURATION  command  or  END  SYSTEM  CONFIGURATION 


of  the  error  and  requesting  re-entry  of  the  parameter,  is  output  to  the  operator  console 


NOTE:  The  modules  'CONFIGURE  SYSTEM-OPTIONS'  and  'CONFIGURE  DISPLAYS'  were  added  to  the  functional 
requirements  late  in  the  design  phase.  Thus  there  is  no  mention  of  them  in  the  requirements 
definition  given  in  Chapters  II  and  III. 


tore  for  PRODUCE  PLANT  DYNAMICS  Branch 


vehicle  altitude  is  zero  or  near  zero 


COMPOTE  TARGET  DYNAMICS.  Using  the  target  mode  selection  Input,  this  module  determines  the  target  mode 
of  operation  (canned  mode,  semi-smart  mode,  smart  mode).  The  corresponding  subordinate  module  Is  then 


Figure  46.  PROCESS  DISCRETE  PLANT  INPUTS  Branch 


Table  VI 


tlons  for  PROCESS  DISCRETE  PLANT  INPUTS 


others 


Table  VII 


COMPUTE  GROUND  MODEL.  This  module  is  an  expanded  version  of  the  air  model,  and  provides  for  vehicle 


Figure  48.  COMPUTE  TARGET  DYNAMICS  Branch 


Table  VIII 


GET  TARGET  TABLES.  This  module  controls  the  input  of  the  target  preprogrammed  tables  and  checks 


for  possible  errors 


the  tables  are  discarded  and  a message,  Informing  the  operator  of  the  error,  is  output  to  the  operator 


Figure  49.  COMPUTE  WEAPONS  DYNAMICS  Branch 


Table  IX 


16  Weapon  input  error  message 


the  associated  weapons 


Figure  50.  COMPUTE  ATTACK  PERFORMANCE  Branch 


HMANCE  Branc 


Figure  51.  MAKEUP  DISPLAYS  Branch 
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Module  Descriptions  for  MAKEUP  DISPLAYS  Branch 


corresponding  display  or  displays,  and  passes  the  HMS  inputs  to  the  appropriate  subordinate  modules 


It  is  possible  and  likely  that  several  of  the  HMD  displays  will  be  aotlve  at  the  same  tine,  with  the 
following  exceptions:  HUD  and  FSD,  WHD  and  TERRAIN  PORTRAYAL,  WHD  and  BACKGROUND/ENVIRONMENT.  Af 


Figure  52.  PROCESS  DISCRETE  DISPLAY  INPUTS  Branch 


in 
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Figure  53.  MAKEUP  TABLE/MENU  BRANCH 


tera  for  MAKEUP  TABLE/MENU  Branch 


Module  Descriptions  for  MAKEUP  TABLEAfflfiU  Branch 


This  nodule  outputs  the  current  HMS  display  to  the  HMD  device 


Figure  54.  MAKEUP  HMD  Branch 


Table  XIV 


HMS  attitude  and  position  inputs,  Vehicle  state 
variables,  Target  state  variables,  Weapons 
state  variables 


Module  Descriptions  for  MAKEUP  HMD  Branch 


quested  by  the  operator,  the  corresponding  module  or  modules  are  called  to  makeup  and  update  the  requested 


Figure  55.  MAKEUP  HUD  Branch 


HOD  Branch 


ters  for  MAKEUP  PANEL  DISPLAY  Branch 


13  Weapons  state  variables,  Attack  performance 


Figure  57.  UPDATE  COCKPIT  INSTRUMENTS  Branch 


tlona  for  UPDATE  COCKPIT  INSTRUMENTS  Branch 


Figure  58.  PUT  RECORDING  Branch 


iters  for  PUT  RECORDING  Branch 


; 


Descriptions 


ters  for  PUT  USER  MESSAGE  Branch 


Figure  60.  GET  PARAMETERS  Branch 


Table  XX 


Figure  61.  PUT  RECORDING  BUFFER  Branch 


This  chapter  has  presented  the  final  bubble  chart  and . structure 
chart  design,  with  their  associated  documentation,  for  the  VCASS  system 
software.  The  preliminary  bubble  chart  was  obtained  from  the  formal 
specifications  in  Chapter  III.  From  the  preliminary  bubble  chart  and 
the  formal  specifications  a first  cut  was  made  of  the  structure  charts. 
This  structure  chart  was  analyzed  relative  to  the  evaluation  criteria 
(coupling,  cohesion,  scope-of-effect,  and  scope-of-control) . Several 
iterations  of  the  structure-to-bubble  chart  and  the  bubble- to-s true ture 
chart  transforms  were  necessary  to  produce  the  final  design . 
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Introduction 


The  design  of  the  VCASS  system  consisted  of  two  main  phases: 
production  of  the  requirements  definition  and  design  of  the  software 
structure.  This  chapter  is  devoted  to  the  discussion  of  the  tech- 
niques used  in  these  two  phases,  some  of  the  problems  encountered, 
and  how  these  problems  were  solved.  The  conclusion  includes  some 
general  observations  and  recommendations. 

Requirements  Definition  Phase 

The  requirements  definition  is  one  of  the  most  difficult  and 
most  important  phases  of  a development  project  (Ref  2:5).  An  analysis 
procedure  used  to  obtain  a complete  and  comprehensive  requirements 
definition  is  SofTech's  Structured  Analysis  Design  Technique  (SADT) 

(see  Ref  5).  This  technique  helps  to  analyse  and  document  "what"  the 
system  is  to  accomplish.  Two  sets  of  diagrams  result:  one  describes 
the  system  in  terms  of  activities  and  the  other  describes  the  system  in 
terms  of  data.  When  the  two  sets  of  diagrams  have  been  developed,  they 
are  then  cross  checked  and  sequenced  to  provide  the  complete  and  com- 
prehensive requirements  definition.  It  was  found  that  for  systems  such 
as  this  one  that  are  not  data  oriented,  the  data  model  does  not  lend 
any  significant  information  to  the  analysis.  It  is  felt  that  the 
amount  of  time  spent  in  developing  the  data  model  was  not  worth  the 
little  added  insight  it  gave.  A discussion  of  the  structured  analysis 
technique  steps  used  in  authoring  the  activity  diagrams  and  how  they 
were  applied  to  this  project  are  contained  in  this  section.  The  same 
steps  were  basically  applied  to  authoring  the  data  diagrams.  (All 


diagrams  referenced  in  the  following  steps  are  contained  in  Chapter 

III). 

Diagram  Authoring  Steps  (Ref  4) : 

1.  Select  Child  to  Decompose.  When  possible , the  first  child 
selected  for  decomposition  is  the  one  which  will  provide  the  most  in- 
depth  information  about  the  parent.  The  information  obtained  by  such 
a decomposition  helps  in  decomposing  the  other  children.  For  example, 
in  the  decomposition  of  node  A1  ( 1 Process  User  Commands  * ) the  child 
A13  (’Configure  System')  was  chosen  to  be  decomposed  first  because  it 
would  detail  what  type  of  inputs  had  to  be  processed.  From  this  informa- 
tion it  was  easier  to  decompose  All  ('Get  Valid  Command'). 

When  decomposing  a parent,  the  "depth"  should  be  consistent 
if  possible.  This  in-depth  consistency  is  not  always  necessary  as  can 
be  seen  from  the  structure  analysis  diagrams  in  this  thesis. 

2.  Gather  Information.  Once  the  child  to  be  decomposed  is 
selected,  all  available  information  which  has  any  bearing  on  this  child 
is  collected.  In  this  project  the  available  sources  of  information 
consisted  of  AMRL  personnel  who  are  associated  with  the  project  and  a 
preliminary  document  describing  a F-16  simulator  written  by  the  Air 
Force  Avionics  Laboratory  (Ref  11). 

3.  Create  a First  Draft  of  the  New  Diagram.  Using  the  informa- 
tion collected,  a list  is  made  of  the  data  to  be  used  by  the  child. 

The  data  list  is  then  grouped  according  to  the  relationships  between 
the  data.  Also  created  is  an  activity  list  based  upon  all  data  rela- 
tionships. An  example  of  the  lists  created  in  the  drafting  of  node  A13 


Data  List 


Vehicle  type 
Vehicle  range 
Vehicle  load  capacity 
Vehicle  maximum  velocity 
Vehicle  stall  velocity 
Vehicle  weapons 

Weapon  types 
Weapon  effective  range 
Weapon  drag  coefficient 
Weapon  quantities 

Dual  or  single  cockpit 
Tjrpes  of  cockpit  instruments 

Canned  target 
Semi-smart  target 
Smart  target 

Windspeed 
Visibility  range 


> Vehicle  parameters 


} 

} 

} 

} 


Weapons  parameters 

Cockpit  parameters 

Target  parameters 

Environment  parameters 


> Activity  List 

Configure  vehicle 
Configure  weapons 
Configure  cockpit 
Configure  target 
Configure  environment 


From  the  activity  list,  the  activity  boxes  and  the  connecting 
data  arrows  are  drawn,  giving  the  first  draft  of  the  new  diagram.  In 
the  development  of  the  activity  model,  an  inability  to  define  input, 
output,  or  control  indicates  a lack  of  understanding  of  that  particular 
activity.  Therefore,  further  study  of  the  system  is  required  until  a 
level  of  understanding  is  obtained  which  allows  development  to  continue. 

4.  Test  Diagram  Quality.  Once  the  draft  of  the  new  diagram  is 
finished,  it  is  tested  for  viewpoint,  purpose,  and  completeness  to 
ensure  that  the  diagram  and  its  parent  are  consistent.  Other  areas  of 
testing  are  amplification  factor  and  balance. 


i 
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The  amplification  factor  test  of  a diagram  should  ensure  the 
Introduction  of  sufficient  information  to  make  the  child  diagram  more 
informative  than  the  parent,  without  having  the  child  be  complex  and 
difficult  to  understand.  If  there  is  insufficient  information  in  a 
diagram  to  make  it  more  informative  than  its  parent,  either  the  dia- 
gram should  be  studied  further  and  redrawn  or  else  the  parent  should 
not  be  decomposed.  Node  A23  contains  such  an  example;  the  decomposi- 
tion of  box  2 would  have  resulted  in  a node  diagram  having  the  same 
description  as  the  parent  (perform  a table  lookup  to  maneuver  the 
canned  target) . 

The  balance  test  ensures  that  all  activities  and  arrows  in  the 
diagram  sire  of  the  same  level  of  detail.  When  the  diagram  balance  is 
not  maintained  at  the  same  level  of  detail,  the  diagrams  become  hard 
for  the  reader  to  follow  and  to  understand.  Thus,  the  major  purpose  of 
the  structured  analysis  diagrams  to  convey  and  clarify  information, 
may  be  lost. 

5.  Write  the  Text.  The  text  to  be  appended  to  a diagram  should 
give  the  reader  a better  understanding  of  what  is  happening  in  that 
diagram.  This  text  should  consist  of  sufficient  information  to 
clarify  the  activity  at  the  described  level  of  detail. 

There  are  two  points  that  aid  in  writing  a good  text.  First, 
the  text  should  be  written  to  clarify  relationships  between  inputs, 
controls,  and  outputs  of  the  different  boxes  of  that  diagram. 

Second,  «n  names  in  the  text  should  be  consistent  with  those  used  on 
the  diagram.  Node  A 2 text  is  an  example  of  a text  that  meets  the 
above  requirements.  When  reading  the  portion  of  A 2 text  given  below 
refer  to  node  diagram  A2. 


•Compute  Weapons  Plant  Dynamics1  (4)  deter- 
mines the  weapons  mode  from  the  weapon  inputs 
(4C3)  and  the  weapon  configuration  (4C4).  The 
vehicle  state  variables  (4C2)  and  the  target 
state  variables  (4C1)  are  then  used  to  control 
the  particular  weapon  mode  by  modifying  and 
updating  the  weapon  state  variables  (401) . 

6.  Modify  Diagram  or  Parent.  Modification  of  a diagram  or  its 
parent  is  required  whenever  an  error  or  an  inconsistency  between  the 
two  is  found.  These  errors  or  inconsistencies  are  found  when  testing 
the  diagram  for  quality  or  when  writing  the  text.  Modification  of  a 
diagram  or  its  parent  is  also  required  when  changes  are  made  to  the 
requirements  definition.  To  correct  the  inconsistencies,  either  the 
diagram,  its  parent,  or  both  are  modified. 

Software  Design  Phase 

The  purpose  of  the  design  phase  is  to  define  the  functions  and 
operations  necessaiy  to  satisfy  the  system  requirements.  Constantine's 
structured  design  (see  Ref  10)  is  a technique  to  describe  the  system 
for  the  programming  phase  of  development.  Two  of  Constantine's  basic 
structured  design  techniques  are  used  in  this  project:  the  transform 
analysis  and  the  transaction  analysis  techniques. 

The  transform  analysis  technique  is  used  on  transform-centered- 
systems,  A transform-centered-system  is  one  in  which  the  major 
system  functions  are  viewed  as  central  transforms  which  use  the  major 
system  inputs  to  create  the  major  outputs.  The  purpose  of  this  tech- 
nique is  to  identify  the  primary  processing  functions  of  the  system, 
the  high-level  inputs  to  those  functions,  and  the  high-level  outputs 
(Ref  10:254).  A detail  discussion  of  this  technique  is  found  in  Ref  10. 

The  transaction  analysis  technique  uses  the  characteristics  of  a 
transaction  center  to  develop  a modular  software  structure.  A 
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transaction  Is  any  element  of  data,  control,  signal,  event,  or  change- 
of-st&te  which  causes,  triggers,  or  inititates  some  action  or  sequence 
of  actions.  A transaction  center  must  be  able  to  obtain  the  trans- 
action, determine  its  type,  dispatch  on  that  type,  and  complete  the 
processing  of  each  transaction  (Ref  10:303).  A more  detailed  dis- 
cussion of  this  technique  is  found  in  Ref  10.  A discussion  of  the 
steps  used  in  these  two  techniques,  including  examples  are  contained 
in  this  section.  These  steps  are  slightly  modified  from  those 
listed  by  Constantine.  (Ref  10:254-328). 

Another  structure  design  technique  used  in  this  thesis  is  that  of 
Hughes  Aircraft  (Ref  1).  This  method  consists  of  iterating  back  and 
forth  between  the  bubble  chart  and  the  structure  design  chart  until 
both  of  these  are  comfortable,  reasonable,  and  functional.  With  this 
iteration  method,  minor  changes  in  the  requirement  definition  can 
be  made  at  anytime  during  the  iteration  process  without  significant 
setbacks  to  the  development  schedule. 

Transform  Analysis  Steps  (Ref  10:254-271): 

1.  Restate  the  Problem  as  a Bubble  Chart.  The  first  problem 
encountered  is  how  to  make  a transition  from  the  structured  analysis 
models  to  the  structure  charts.  This  transition  is  accomplished 
through  the  use  of  a bubble  chart.  Prom  the  formal  requirements 
definition  specified  in  the  structured  analysis  models,  a preliminary 
bubble  chart  is  drawn  to  show  the  flow  of  data  through  the  system  and 
the  transformations  on  that  data.  The  preliminary  bubble  chart  drawn 
for  this  project  is  shown  in  Figure  62. 

2.  Identify  the  "Afferent"  and  "Efferent"  Data  Elements  on  the 
Bubble  Chart.  The  initial  identification  is  shown  in  Figure  62. 
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Figure  62.  Preliminary  Bubble  Chart 
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"Afferent  data  elements  are  those  high-level  elements  of  data  which 
are  furthest  removed  from  physical  inputs,  yet  which  still  constitute 
inputs  to  the  system"  (Ref  10:262).  "Efferent  data  elements  are 
those  furthest  removed  from  the  physical  outputs  which  may  still  be 
regarded  as  outgoing"  (Ref  10:263).  The  transforms  in  the  middle 
between  the  "afferent"  and  the  "efferent"  data  elements  are  designated 
as  "central  transforms". 

3.  Develop  a Fully  Factored  "First-Cut"  Structure.  First,  a main 
module  ('VCASS  SUPERVISOR*)  is  defined  to  call  upon  subordinates  to 
perform  the  system  tasks.  Second,  the  "afferent"  modules  ('PROCESS 
COMMAND*  and  'GET  ANALOG  AND  DIGITAL  INPUTS')  are  made  subordinate  to 
•VCASS  SUPERVISOR'.  Their  functions  are  to  deliver  the  system  inputs 
to  their  superordinates.  Third,  the  "central  transform"  module 
('PRODUCE  PLANT  DYNAMICS')  is  made  subordinate  to  'VCASS  SUPERVISOR'. 
Its  function  is  to  accept  input  data  from  its  superordinate,  trans- 
form the  input  data  into  the  appropriate  output  data  (plant  dynamics), 
and  return  the  output  data  to  the  superordinate.  Lastly,  the  "efferent" 
module  ('PERFORM  AIRCRAFT  SIMULATION')  is  also  made  subordinate  to 
•VCASS  SUPERVISOR*.  The  function  of  'PERFORM  AIRCRAFT  SIMULATION' 
is  to  accept  the  plant  dynamics  from  the  supervisor  and  transform  it 
into  display  data  for  output.  The  results  of  this  "first-cut"  top- 
level  factoring  is  shown  in  Figure  63.  The  method  used  for  factoring 
of  these  three  type  of  modules  was  accomplished  by  the  use  of  the 
appropriate  structured  analysis  diagrams  (Chapter  III).  Because  of 
the  size  of  the  system,  it  would  be  impractical  to  show  the  complete 
■first-cut"  structure  chart.  (Note:  many  of  the  nodes  of  the 
structured  analysis  diagrams  correspond  directly  as  modules  in  the 
structured  design.) 
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Figure  63.  "First-Cut"  Top-Level  Structure  Chart 
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4.  Analyze  and  Redraw  (as  necessary)  the  "First-Cut"  Structure 
Chart.  This  is  accomplished  by  evaluating  the  structure  chart  as  to 
the  following  attributes:  coupling,  cohesion,  span-of-control,  and 
scope-of-effect. 

When  the  "first-cut"  structure  was  analyzed  it  became  evident 
that  placing  the  module  'GET  ANALOG  AND  DIGITAL  INPUTS'  at  the  top 
level  caused  input  control  data  to  be  passed  down  several  module  levels 
before  the  data  was  used.  This  created  unnecessary  control  coupling 
throughout  the  structure.  The  problem  was  solved  by  making  each  module 
responsible  for  obtaining  the  inputs  which  it  needed.  Figure  47 
(Chapter  IV)  illustrates  such  an  example.  The  vehicle  inputs  obtained 
by  the  modules  in  this  example  are  obtained  indirectly  6/  a call  to 
the  module  'GET  VEHICLE  PARAMETERS',  rather  than  being  passed  down 
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from  the  top  of  the  structure 


Cohesion  and  coupling  are  interrelated.  The  lower  the  coupling 
between  any  pair  of  modules,  the  greater  the  cohesion  of  the  individual 
modules  (Ref  10:144).  This  was  found  to  be  true.  When  coupling 
problems  were  solved,  a satisfactory  level  of  cohesion  existed  within 
the  modules.  For  example,  when  the  coupling  problem,  discussed  above, 
was  resolved  the  cohesion  of  the  input  modules  improved.  In  the 
"first-cut"  structure,  in  which  the  inputs  were  obtained  at  the  top 
level  through  the  module  'GET  ANALOG  AND  DIGITAL  INPUTS',  many  of 
the  lower  level  input  modules  were  logically  and  communi cationaly 
cohesive.  (Logical  cohesive  modules  are  those  that  perform  a general 
function  and  communicational  cohesive  modules  are  those  which  comprise 
several  logical  functions  operating  on  some  data  (Ref  10:153,  161).) 

This  was  due  to  the  fact  that  the  input  modules  at  this  level  had  to 
collect  different  inputs,  group  them,  and  pass  them  on.  After  the 
coupling  problem  was  resolved,  by  placing  the  input  modules  subordinate 
to  the  modules  which  directly  uses  the  input  data,  the  input  modules 
became  functionally  cohesive.  (Functional  cohesive  modules  are  those 
that  perform  a single  specific  function  and  are  the  most  desirable 
type  of  modules  (Ref  10:170).) 

Making  the  scope-of-effect  and  scope-of-control  coincide  was 
not  a significant  problem  in  the  design  of  the  VCASS  simulator.  One 
place  that  they  do  not  coincide  was  in  the  'CONFIGURE  SIMULATION'  branch 
(Figure  44,  Chapter  IV);  they  could  have  been  made  to  coincide  by 
designing  the  structure  as  shown  in  Figure  64. 

The  problem  with  the  structure  in  Figure  64  is  that  the  design  is 
not  balanced.  Each  of  the  'CONFIGURE'  modules  is  logically  equivalent 
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Figure  64.  Alternate  CONFIGURE  SIMULATION  Branch 

pnd  should  not  be  subordinate  to  the  others.  The  scope-of-effect 
which  exists  between  some  of  the  modules  is  small  and  therefore  is  not 
as  important  as  maintaining  a balance  in  the  design.  An  example  of 
this  small  scope-of-effect  is  easily  seen  between  the  modules 
•CONFIGURE  VEHICLE'  and  'CONFIGURE  WEAPONS'.  The  vehicle  type  dictates 
what  type  of  weapons  and  how  many  it  can  carry,  but  reveals  nothing 
about  the  many  individual  characteristics  of  the  weapons. 
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5.  Iterate  Procedure.  Using  the  Hughes  Aircraft  Method,  iterate 
between  the  structure  chart  and  the  bubble  chart  until  both  types  are 
comfortable,  reasonable,  and  functional.  This  iteration  procedure 
was  found  to  be  very  useful  to  "fine  tune"  the  requirements  definition 
throughout  the  design  phase. 

A significant  problem  that  was  encountered  during  the  iteration 
process  was  where  to  accomplish  the  operational  recording  within  the 
structure.  This  problem  was  later  solved  when  AMRL  specified  that  all 
the  recording  information  was  to  be  contained  at  a single  specified 
buffer  location  and  periodically  dumped  to  a recording  device.  It 
was  then  decided  to  make  the  recording,  module  ('PUT  RECORDING')  in- 
dependent from  the  other  modules.  Other  modules  would  dump  new  data 
into  the  recording  buffer  and  the  recording  module  would  output  the 
buffer  when  activated  by  the  "supervisor".  Thus,  the  recording  module 
became  immediately  subordinate  to  the  module  'VC ASS  SUPERVISOR'. 


Transaction  Analysis  Steps  (Ref  10:  307-308): 


1.  Identify  a Transaction  Center.  When  the  transfoim  analysis 
procedure  was  applied,  some  of  the  lower  level  modules  were  found  to 
be  transaction  centered.  One  such  module  is  'MAKEUP  HMD'  (Reference 
Figure  54,  Chapter  IV).  This  module  and  corresponding  figure  are 
used  for  the  example  in  the  following  steps  and  should  be  referenced. 


2.  Identify  the  Transactions  and  Their  Defining  Actions. 
Transaction  Action 


WHD  mode 

Terrain  Portrayal  mode 
Background/Environment  mode 
HUD  mode 
FSD  mode 


Makeup  the  WHD  display 

Makeup  the  Terrain  Portrayal  display 

Makeup  the  Background/Environment  display 

Makeup  the  HUD  display 

Makeup  the  FSD  display 
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3.  Note  Potential  Situations  Where  Modules  can  be  Combined. 

In  this  example  each  transaction  is  a separate  and  distinct  mode  or 
state;  therefore,  none  of  the  modules  can  be  combined.  If,  in  the 
future  some  of  the  displays  were  to  be  combined  to  reduce  cockpit 
clutter  for  the  pilot  or  if  two  of  the  displays  were  found  to  be 
almost  similar,  then  this  would  be  an  example  where  two  modules  could 
be  combined. 

4*  Specify  a "Transaction"  Module  for  Each  Transaction. 

From  the  transaction  list  in  Step  2 the  following  "transaction" 
modules  were  specified  to  supervise  the  corresponding  transaction. 

Transaction  Transaction  Module 

WHD  mode  MAKEUP  WHD 

Terrain  Portrayal  mode  MAKEUP  TERRAIN  PORTRAYAL 

Background/Environment  mode  MAKEUP  BACKGROUND/ENVIRONMENT 

HUD  node  MAKEUP  HUD 

FSD  mode  MAKEUP  FSD 

5.  Specify  a Subordinate  "Action"  Module.  See  explanation  under 

6. 

6.  Specify  Appropriate  Subordinate  "Detail"  Modules.  Due  to 
an  incomplete  requirements  definition  in  the  area  of  displays,  the 
"action"  and  "detail"  modules  of  this  transaction  center  were  not 
specified.  Later,  as  AMRL  further  defines  the  detailed  display  re- 
quirements the  "transaction"  nodules  can  be  expanded  to  complete  steps 
5 and  6.  The  "transaction"  module  'MAKEUP  HUD'  is,  also,  a transaction 
center  and  these  same  six  steps  are  applied  to  its  design. 

Finalizing  the  Design.  After  the  "final"  structure  chart  is  drawn  and 
before  programming  begins,  the  associated  design  documentation  should 
be  prepared.  This  is  accomplished  by  creating  an  input/output  para- 
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meter  list  along  with  a module  description  of  each  module.  This 
design  documentation  will  give  the  programmer  a basic  understanding 
of  what  each  module  does  and  how  it  interfaces  with  the  rest  of  the 
system.  The  programmers  should  then  be  able  to  flow  chart  and 
program  each  module  with  minimal  difficulties. 

When  the  associated  design  documentation  is  finished,  it,  along 
with  the  "final”  structure  charts,  are  given  to  the  appropriate 
people  for  a final  design  review.  During  this  review,  the  design  is 
scrutinized  and  checked  to  ensure  conformity  to  the  established 
requirements  definition.  Possible  problems  are  also  noted,  recom- 
mendations made,  and  remedies  proposed.  For  this  project,  AMRL 
conducted  the  final  design  review.  Their  remarks  and  recommendations 
were  analyzed  and  the  design  modified  accordingly.  The  results  of 
this  final  design  review  produced  the  "final"  structure  chart  design 
contained  in  Chapter  IV. 

Observations  and  Recommendations 

When  answering  the  questions  that  arise  in  defining  the  formal 
functional  specifications  for  a proposed  system,  an  organization  is 
forced  to  make  concrete  decisions  about  what  they  want  the  system  to 
accomplish.  This  aids  in  organizing  the  varied  ideas  and  concepts  of 
"how"  the  system  is  to  perform.  It  was  found  to  be  very  important 
to  periodically  hold  system  development  meetings.  These  will  save 
time,  will  facilitate  the  answering  of  questions  that  arise,  and  will 
foster  the  exchange  of  ideas  and  recommendations. 

Many  of  the  bottom  level  modules  for  creating  and  assembling 
the  displays  (Figures  53  and  56)  need  further  decomposition  to 
better  define  their  functions.  The  modules  have  not  been  decomposed 
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in  this  thesis  because  AMRL  has  not  yet  defined  the  detailed  display 
requirements.  These  modules  are  so  structured  that  they  can  be 
% examined  and  decomposed  further,  as  required,  without  effecting  other 

modules  in  the  system. 

The  programmers  that  implement  this  design  should  be  familiar 
with  the  structure  design  techniques  as  contained  in  Kef.  10.  This 
will  help  them  to  better  code  the  different  modules.  The  structure 
charts  should  be  studied  by  the  programmers  to  clarify  any  vague 
portions  of  the  design.  If  further  decomposition  is  needed  for  a 
module,  it  should  be  accomplished  before  the  coding  is  started.  To 
be  consistant  with  the  software  life-cycle  (discussed  in  Chapter  II ) 
each  module  should  be  flowcharted  for  coding.  These  flow  charts  will 
provide  a more  rigorous  specification  for  the  modules  than  the  formal 
functional  specifications  given  in  Chapter  IV. 
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Appendix  A 

STRUCTURED  ANALYSIS  DIAGRAMS 


Introduction 

This  appendix  contains  a brief  explanation  of  the  functional 
analysis  phase  of  structured  analysis  to  aid  the  reader  in  understanding 
the  development  of  the  design  structure.  A more  detailed  discussion  can 
be  found  in  Ref  7. 

Structured  Analysis 

Structured  analysis  is  a comprehensive  methodology  for  performing 
functional  analysis  and  design.  In  the  functional  analysis  phase,  the 
emphasis  is  on  analyzing  and  documenting  "what"  the  system  is  supposed 
to  do.  Two  sets  of  diagrams  result:  one  describes  the  system  in  terms 
of  activities,  the  other  describes  the  system  in  terms  of  data.  These 
diagrams  are  created  by  decomposing  the  system  into  smaller  and  smaller 
pieces.  The  two  sets  of  diagrams  are  cross-checked  and  sequenced  to 
provide  a model  of  the  system  functions. 

Diagram  Syntax 

Structured  analysis  diagrams  consist  of  labeled  boxes  and  arrows 
for  expressing  the  system  activity  and  data  models,  figure  65  illustrates 
the  basic  syntax  of  the  models.  Inside  a box  is  the  name  of  the  activity 
model  or  data  model.  For  an  activity  model  the  name  expresses  the  action 
taking  place.  For  a data  model  the  name  is  a noun  or  noun  phrase  ex- 
pressing the  data  item. 
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Figure  65. 

Box/interface  Arrow  Conventions 

The  boxes  of  the  parent  diagram  are  decomposed  into  more  detaile 
diagrams  called  children.  Each  diagram  is  numbered  in  a Dewey-decimal 
manner  (Ref  7:  2-3),  which  represents  the  parent-child  relationship. 
Diagrams  3 11,  312,  313,  and  314  would  be  children  of  diagram  31.  Each 
diagram  is  referenced  as  a node. 

The  boxes  of  a diagram  are  connected  by  arrows  which  represent 
the  interface  between  the  boxes.  The  sides  of  the  box  defines  the  kind 
of  arrow(s)  which  may  enter  or  leave  that  side  of  the  box. 

Four  types  of  arrows  represent  the  kinds  of  interface.  As  in 
reference  7:  3-6,  these  are: 

A.  Activity  Diagrams: 

1.  Input:  Data  transformed  by  the  activity  into  the  output. 

2.  Output:  Data  created  by  the  activity. 


3.  Control:  Data  used  to  control  the  process  of  converting 
i the  input  into  output. 

t 


B.  Data  Diagrams: 

1.  Input:  Activity  which  creates  the  data. 

2.  Output:  Activity  which  uses  the  data. 

3.  Control:  Activity  which  controls  the  creation  or  use 
of  the  data. 

4.  Mechanism:  The  storage  device  used  to  hold  the  data 
(buffer,  computer  memory,  etc.) 

It  should  be  noted  that  the  "mechanism"  arrow  represents  the 
tool  necessary  to  "realize  the  box"  (Ref  7:  3-4)  j since  it  is  usually 

evident  from  the  title  of  the  box  the  "mechanism"  arrow  is  not  always 
shown. 

The  "mechanism  call"  arrow  points  downward.  This  indicates  a 
separate  system  which  completely 
performs  the  function  of  the  box. 

In  such  cases  there  will  be  no 
child  diagram  of  the  box  and  its 
detail  would  be  found  in  a separate 
model  of  the  mechanism.  This 
"mechanism  call"  is  illustrated 
in  Figure  66. 

The  "multiple  branch" 

(EXCLUSIVE  OR)  is  used  to  indicate 
multiple,  but  not  simultaneous , 
outputs.  The  "multiple  join" 
indicates  multiple,  but  not 
simultaneous,  inputs.  Both  con-  Figure  66,  Mechanism  Call  Arrow 

▼entions  are  illustrated  in 
Figure  67. 
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TWO-WAY  BRANCH 


Figure  67.  OR  Branch  and  Join  Structure 

An  "I COM  Code"  is  used  to  connect  arrows  across  the  parent/child 
boundaries.  The  name  ICOM  is  derived  from  the  arrow  names:  input, 
control,  output,  and  mechanism.  Each  boundary  crossing  arrow  (ones 
which  do  not  have  both  ends  connected  to  a box)  is  labeled  with  its 
parent-context  ICOM  code,  in  addition  to  its  normal  label.  This  aids 
the  reader  in  locating  the  matching  parent  arrow.  The  "ICOM  Code"  is 
written  near  the  unconnected  end  of  the  arrow  and  consists  of  the 
letter  I,  C,  0,  or  M followed  by  a number.  This  number  gives  the 
relative  position  that  the  arrow  enters  or  leaves  the  side  of  the 
parent  box.  Numbering  is  done  from  left  to  right  and  top- to -bottom 
as  illustrated  in  Figure  68.  For  example,  "C2"  on  an  arrow  in  a 
child  diagram  indicates  the  arrow  is  the  second  control  arrow  entering 
the  parent  box. 

In  the  text  associated  with  each  diagram,  the  arrows  are  identified 
with  an  "ICOM  code"  consisting  of  a letter  (I,  0,  C or  M),  a prefix 
number,  and  a suffix  number.  The  prefix  number  refers  to  the  box 
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within  the  diagram  and  the  suffix 
number  refers  to  the  top-down  or 
left-right  order  of  the  arrow 
on  the  box.  For  example,  n2C3n 
means  the  third  control  going 
into  box  2 on  the  diagram. 


Reading  Sequence  (Ref  7:4-2) 


The  following  sequence 
is  suggested  for  reading  each 
diagram  in  a top-down  order. 

1.  Scan  only  the  boxes  of  the  diagram  to  gain  a first  impression 
of  its  decomposition. 

2.  Using  the  parent  diagram,  rethink  the  message  of  the  parent, 
observing  the  arrows  feeding  to  and  from  the  current  diagram.. 

3.  Referring  back  to  the  current  diagram,  see  how  and  where  each 
arrow  from  the  parent  context  attaches  to  the  factors  in  the  current 
diagram;  using  I COM  codes. 

4.  Consider  the  internal  arrows  of  the  current  diagram  to  see 

• < 

how  it  works  in  detail.  Consider  the  boxes  from  top  to  bottom  and  from 
left  to  right.  Examine  the  arrows  by  going  clockwise  around  each  box. 

5.  Finally,  read  the  text  of  the  current  diagram  to  confirm  or 
to  alter  the  interrelation  gained  from  consideration  of  the  diagrams 
themselves. 


Cl  C2  Cn 


•Ol 

■02 


•On 


Figure  68.  I COM  Numbering  Convention 


Appendix  B 

STRUCTURED  DESIGN  CHARTS 


Introduction 

This  appendix  contains  a brief  explanation  of  structured  design 
in  order  that  the  reader  may  understand  the  development  and  the  reading 
of  the  structured  charts.  A more  detailed  discussion  can  be  found  in 
Ref  9. 

Structured  Design 

Structured  design  is  a set  of  general  program  design  considerations 
and  techniques  for  making  coding,  debugging,  and  modification  easier, 
faster,  and  less  expensive  by  reducing  complexity  (Ref  8:  115).  It 

simplifies  the  software  by  dividing  it  into  modules  in  such  a way  that 
the  modules  can  be  implemented  and  modified  with  minimal  effect  on 
other  parts  of  the  system. 

Structured  design  starts  by  stating  a problem  as  a data  flow  graph, 
or  bubble  chart.  A first  cut  is  obtained  by  factoring  the  bubble  chart 
into  a tree  structure.  The  resulting  design  is  then  evaluated. 

The  criteria  for  evaluating  the  design  are  coupling  and  cohesion. 
Coupling  is  a measure  of  the  relationship  between  modules,  and  cohesion 
is  a measure  of  the  relationships  among  elements  in  the  same  module. 

The  objective  is  to  minimize  coupling  and  to  maximize  cohesion.  Other 
criteria  to  be  considered  are  the  scope-of-effect  and  the  scope-of- 
control.  Scope-of-effect  is  the  collection  of  all  modules  containing 
any  processing  that  is  conditional  upon  a particular  decision.  Scope- 
of-control  is  a module  and  all  of  its  subordinates.  The  objective  is 


Figure  69.  Information  Flow 


to  have  the  scope-of -effect  and  the  scope-of-control  coincide. 


Structured  Chart  Syntax 

Structured  charts  consist  of  modules  connected  either  to  modules 
and/or  to  data  bases  by  information  flow  lines  or  by  connection  lines. 
Figure  69  illustrates  the  basic  syntax  for  connecting  modules  and  data 
bases.  The  solid  line  represents  a normal  connection.  A dashed  line 
represents  a transfer  of  control  which  takes  place  automatically, 
asynchronously  or  concurrently  with  established  processes.  This  includes 
program  interrupts  and  parallel  subroutine  calls.  (Note  that  the  data 
base  is  designated  by  a rectangle  with  curved  sides.)  Connections  are 
ordered  left-to-right  as  they  emerge  from  the  referencing  module  in  the 
same  order  that  they  would  usually  be  accessed.  The  arrows  adjacent 
to  any  connection  indicate  the  direction  of  the  flow  of  information. 
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